Large projects involving many people and/or groups who facilitate different aspects of the project are preferably managed and organized so that the project yields the requested results as efficiently and inexpensively as possible. For example, in the field of network telecommunications, when a client orders network service from a network service provider, delivering the network infrastructure and service is typically a very involved and complex process over the life of the project. Prior systems for managing large projects, such as network service provisioning, often have drawbacks related to inefficiency and redundancy.
Large projects can span many months or even years, and can involve many different tasks and groups. In such large projects it can be very difficult for upper level management to obtain a view of the status of the entire project at any given point in time. Some companies use work flow engines to manage projects. Work flow engines typically automate the flow of paperwork from person to person involved in the project, task management via documents, and so on. Although work flow engines have been fairly effective in facilitating the project tasks, these systems have historically required a great deal of software and the deep involvement of the information technology group within the organization. For example, specialized code would need to be developed to track the various steps in the workflow. When the workflow changed, the code would need to be changed. In industries where time is critical, the need to update code when any change to work flow arises is a great burden.
In implementing long term projects companies need to be able to respond quickly to changing circumstances. For example, when a network service provider implements a new private line network to a business client, changes may occur at various times in the project that impact various departments of the network service provider. In this example, the changes may occur due to changes in client requirements or changes in assumptions, such as component availability or worksite geography or zoning. Some of these changes could dictate that previously done work must be redone, or previously made preparations must be reassessed. For example, new types of components may need to be ordered or the network may need to be rerouted. Such changes may affect many aspects of the project, such as order entry, billing, inventory management, or engineering. At a minimum the network service provider must be able to quickly determine whether the changes can be made at all; e.g., it may be too late in the process to reroute the network. If the changes can be made, the company should be able to quickly determine new costs, if any, tasks to be reworked, possible changes to downstream requirements, and so on.
It is with respect to the foregoing and other problems that embodiments of the present invention have been created.